The Other Kind of Accessible

Removing software barriers for disabled researchers and RSEs

Eli Chadwick (he/him and they/them)

The Carpentries

5 September 2023

Introduction

Introduction

  • RSE for 5 years
  • SSI Fellow since 2021
  • Currently an IT Developer at The Carpentries
  • Use voice control and eye tracking software due to chronic RSI
  • Started studying disability and accessibility after discovering how much harder it was to use the web with assistive tech

What is the “Other Kind of Accessible”?

“Accessible” in FAIR for research software

Findable: Software, and its associated metadata, is easy for both humans and machines to find.

Accessible: Software, and its metadata, is retrievable via standardised protocols.

Interoperable: Software interoperates with other software by exchanging data and/or metadata, and/or through interaction via application programming interfaces (APIs), described through standards.

Reusable: Software is both usable (can be executed) and reusable (can be understood, modified, built upon, or incorporated into other software).

None of these explicitly say that software should be usable by all types of people!

“Accessible” in a disability context

Ensures that everyone, including people with disabilities, older adults, and people from diverse cultural and linguistic backgrounds, can access and participate fully in society. This includes access to physical spaces, transportation, digital content, and communication.

Digital Accessibility, a.k.a. “a11y”

a11y is a numeronym - like an acronym, but with numbers

There are 11 letters between the ‘a’ and ‘y’ in ‘accessibility’!

Typically pronounced “ah-lee” or “A-eleven-Y”

Types of Disability

  • Visual
  • Auditory
  • Speech
  • Mobility/Body Structure (e.g. fine motor control, ambulation, muscle fatigue)
  • Cognitive (e.g. learning, reading, attention, sensory sensitivity)
  • Seizure
  • Psychological/Psychiatric (e.g. social, behavioural, mental health)

A person may have multiple disabilities, which may or may not intersect.

Type of disability Barriers in software
Visual Colour, text size, screen reader incompatibility
Auditory Lack of captions/sign language interpretation
Speech Lack of text-based alternatives for speech communication
Mobility Operating specific controls
Cognitive Complex page layout, animations, long or complex text
Seizure Moving, blinking, or flickering content
Psychological
All Lack of support, reduced access to events, lack of representation

Why Should I Care About This?

I don’t have disabled users!

  • Are you sure?
  • Are you sure that you will never have disabled users?
  • Are disabled people who want to be your users turned away at the point of entry?
    • They will not tell you
    • They will just leave

Accessibility benefits everyone…

…but it benefits disabled people most

Statistics

Chart showing percentage of higher education staff and students with known disabilities from academic year 2017/18 to 2021/22. 2021 census data for the general population is shown at 18%. 'All undergraduate' rises from 14% to 18%. 'All postgraduate' rises from 9% to 11%. 'Other contract level' rises from 4% to 7%. 'Other senior academic' rises from 3% to 5%. 'Professor' rises from 2% to 3%. Sources: HESA, ONS

Chart showing percentage of higher education staff and students with known disabilities from academic year 2017/18 to 2021/22. 2021 census data for the general population is shown at 18%. 'All undergraduate' rises from 14% to 18%. 'All postgraduate' rises from 9% to 11%. 'Other contract level' rises from 4% to 7%. 'Other senior academic' rises from 3% to 5%. 'Professor' rises from 2% to 3%. Sources: HESA, ONS

Chart showing percentage of higher education staff and students with known disabilities from academic year 2017/18 to 2021/22. 2021 census data for the general population is shown at 18%. 'All undergraduate' rises from 14% to 18%. 'All postgraduate' rises from 9% to 11%. 'Other contract level' rises from 4% to 7%. 'Other senior academic' rises from 3% to 5%. 'Professor' rises from 2% to 3%. Sources: HESA, ONS

Models of Disability: Medical model

  • Disability is the result of an impairment
  • Treatment aims to ‘fix’ the disability or provide special individual services
  • The disabled individual is expected to take the responsibility for adjusting
  • “She can’t read the newspaper because she is blind”

Models of Disability: Social model

  • Disability is the result of barriers in society; separate to impairment
  • A person may be more disabled by some environments than others
  • It is everyone’s responsibility to remove barriers that disable people
  • “She can’t read the newspaper because it’s not published in large text or Braille”

The social model is broadly preferred by the disabled community

Ask yourself: what barriers exist within my software that I could remove?

It’s the law

UK Equality Act 2010

  • “…where a provision, criterion or practice of A’s puts a disabled person at a substantial disadvantage… take such steps as it is reasonable to have to take to avoid the disadvantage.”

Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018

  • You must make your website or mobile app more accessible by making it ‘perceivable, operable, understandable and robust’. 1

What Can I Do?

Disclaimer

A lot of the resources I share are focused on web development

But there are parts that apply to every project, be it web, GUI, or CLI

I’m a developer

Basic checks:

  • Try completing tasks with only the keyboard, or only the mouse
  • Try different visual settings (200% zoom, high contrast, greyscale)
  • Check your use of colour (good contrast, other styling)
  • [web only] Try an automated testing tool such as WAVE

Or pick a checklist to follow for a deeper dive:

I create papers, blog posts, videos…

  • Check use of colour
  • Ensure non-decorative images have alt text
  • Provide a text alternative for complex images such as charts, graphs, maps
  • Ensure videos have human-generated captions and/or transcripts

I guide project direction

  • Set a11y requirements and targets for development
    • e.g. use automated a11y tests in CI (we use pa11y)
  • Prioritise a11y in the planning process
    • treat a11y issues as bugs!
  • Arrange user testing, including disabled users
  • Arrange a professional a11y audit

I guide organisational direction

I can influence funding bodies

  • Push for a11y to be prioritised in all research outputs (including but not limited to software)
  • Reward grant applications that describe how they will consider and design for disabled users

I want to learn more

Talk to me if you’d like to be part of an a11y-focused subcommunity/learning group!

Questions

Thank you for your attention!

Contact me:

  • elichadwick@carpentries.org
  • Eli Chadwick - UKRSE Slack (the profile that says I’m at The Carpentries)
  • Chat to me at any break or social during RSECon!

Find these slides at https://elichad.github.io/talks